This ugly PoC now works and boots on x230-maximized, with lotsa screen tearing.
Not sure where and how to enable simplefb double buffering here to remove some of the ugly hacks under patches.

@JonathonHall-Purism if you have any insights, or want to reuse parts of this or wnat me to test things, let me know!

This is hard to compare against 4.14 here, but the x230-maximized rom here has 500kb freer then the 4.14 rom on master.

As said earlier, qemu is not able to refresh the qemu gtk drawer for some obsuce reason on latest version provided by debian-11

user@heads-tests:~/heads$ qemu-system-x86_64 --version
QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-11+deb11u2)
Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers

Next steps:
Try removing unneeded options above related to Linux fb ownership (which parents resettled in kexdc'ed kernel):

• CONFIG_FB_TILEBLITTING
• CONFIG_FRAMEBUFFER_CONSOLE_ROTATION

Also, fbwhiptail per this savage PoC is currently launched in single buffer mode(FBWHIPTAIL_LINUXFB_SINGLE=1 fbwhiptail...) from patched whiptail script wrapper under fbwhiptail patch against git master version which also savagely rips error management when vsync ioctl happens and when panning is expected to be possible on fb buffer.

To have proper double size buffer:

• is coreboot supposed to setup the double buffer?
• Linux is supposed to double it?

Interesting: simple DRM is provided in kernel 5.14+
https://cateee.net/lkddb/web-lkddb/DRM_SIMPLEDRM.html

config DRM_SIMPLEDRM
tristate "Simple framebuffer driver"
depends on DRM && MMU
select APERTURE_HELPERS
select DRM_GEM_SHMEM_HELPER
select DRM_KMS_HELPER
help
DRM driver for simple platform-provided framebuffers.

This driver assumes that the display hardware has been initialized
by the firmware or bootloader before the kernel boots. Scanout
buffer, size, and display format must be provided via device tree,
UEFI, VESA, etc.

On x86 BIOS or UEFI systems, you should also select SYSFB_SIMPLEFB
to use UEFI and VESA framebuffers

.

Check if back ported into 5.10.178 and test, otherwise if work and only provided in later version, might be good reason to kernel version bump (to use fbwhiptail in DRI mode and not linuxfb mode). See https://source.puri.sm/firmware/fbwhiptail/-/commits/1.1/

Edit: this commit seems to shed some light on error I get on qemu of debian-12 torvalds/linux@7fcf193

Seems like simpledrm might be the answer of lack of refresh with VGA std on qemu.To be tested: two birds one stone.

Check if back ported into 5.10.178 and test, otherwise if work and only provided in later version,

Unfortunately, drivers/gpu/tiny/simpledrm.c is part if 5.15+ and wasn't back ported to 5.10.179. Also noted that bochs is part of tiny DRM support,which might be enough to have similar setup for qemu and hardware based platforms. Note that libgfxinit is only for Intel, that native init is possible (AST, AMD and others gave native gfx init under coreboot).

Will need kernel bump for testing.
It is to be noted that newer platforms require 6.x for newer i915 driver on newer intel platforms. Maybe that could dodge that as well, and let deeper support to the
kexec'ed OS.

Will try lower effort 5.15 and report back. We want LTS under Heads if possible.

I think this is a great solution, and this may be a better way to get framebuffer OS boot working on the servers than more kernel hacking.

I have not dug into it yet, but it sounds like fbwhiptail is using the LinuxFB backend in "single buffer" mode, which means it draws directly into the backbuffer (so you see all the drawing, this is worse than just "tearing" frames due to lack of vsync).

What we need to do is adapt the shadow-buffer method of the DRI backend (in fbwhiptail 1.1) to work for LinuxFB in single buffer mode as well. So the DRI / LinuxFB part only determines where the framebuffer comes from, and in both cases we draw into a shadow buffer, then blit the contents over to the real framebuffer.

I'm happy to look into it, but it'll be some time before it reaches the top of my to-do list as I have some high priority work right now.

Some notes digging this down on 5.15 latest (will edit):

• CONFIG_DRM_FBDEV_OVERALLOC is where simpledrm sets double or tripple buffer alloc is made by percentage. Default is 100. Putting to 300. No impact since not able to use simpledrm with either google firmware enable fb or sys_fb as of now
• CONFIG_DRM_FBDEV_EMULATION is needed for above
• CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM should not be needed, to confirm?
• CONFIG_DRM_SIMPLEDRM seems to replace SIMPLEFB? Yes it does, and it disables google firmware enabled FB....
• FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION needed? Doesn't seem needed
• CONFIG_FRAMEBUFFER_CONSOLE_ROTATION should not be needed. Is not needed
• CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER should be needed (otherwise black screen until fbcon loads) NEEDED
• CONFIG_DRM_BOCHS should not be needed for qemu/kvm with vga std (simpledrm should work)? SimpleDRM doesn't work. It seems that coreboot bochs support should be replaced by implementation of simpledrm.
• CONFIG_FB needed (Nothing selected under that under device->graphics->frame buffer devices)
  • As of now:
    • CONFIG_FIRMWARE_EDID is on for firmware transfer?
    • CONFIG_FB_MODE_HELPERS for Generalized Timing Formula Parser and EDID parser?
    • CONFIG_FB_MODE_HELPERS needed?

So simpledrm doesn't expose fb base address: simplefb does.
And for fbwhiptail to play nice with simplefb, additional work is needed.

It seems that the way to go forward would be to bump boards depending on kernel 4.14 to 5.10.5 with i915drm, have coreboot depend on libgfxinit for intel boards to show early bootsplash and have the console/fb owned by drm drivers under Heads, with in tree VLFB kexec hack (and kernel fb leak option configured, and then coreboot passing the option) so that next kexec call can reuse exposed fb address to boot even into VESA (test case working for tinycore which only contains vesafb driver and drives the console correctly.

But that would need to change later on when fbwhiptail is modified to work correctly with simplefb which is the preferred unified way forward, since simplefb is able to do the same, without having drm stack into Heads kernel.

So simpledrm doesn't expose fb base address: simplefb does.

Interesting. Can you elaborate? Should it be in /sys or /proc?

Interesting. Can you elaborate? Should it be in /sys or /proc?

Sorry, my recap might have been a bit too simple to sum up the whole adventure here.

From what I understand, linux moved away of exposing addresses in a faster pace since 5.x.
Heads, since a long while if not its near beginning, implemented a hack into kexec to be able to expose fb address on kexec call https://github.com/osresearch/heads/blob/master/patches/kexec-2.0.26.patch#L60. That worked for linux 4.14 without additional hack.

Comes 5.x which prevents leaking of fb address. inteldrm name changed to i915drmfb https://github.com/osresearch/heads/blob/master/patches/kexec-2.0.26.patch#L61, while https://github.com/osresearch/heads/blob/master/patches/kexec-2.0.26.patch#L48-L50 is now needed as well (CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM needs to be configured in kernel, and coreboot needs to pass linux command line option drm_kms_helper.drm_leak_fbdev_smem=1 for the kexec'ed kernel to be able to go VESA mode (tinycore ISO is good test case here since no other fb driver is provided but vesafb, which works in this configuration).

In the case of simpledrm, those hacks don't work and fall into this case, even if VLFB hack on kexec has simpledrm passed on https://github.com/osresearch/heads/blob/master/patches/kexec-2.0.26.patch#L95. But this works properly with simplefb (simple is the name of the driver).

Basically, simpledrm, as most of the other drivers but Intel, are not respecting CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM and consequently don't expose base address.

When libgfxinit is used, the linear framebuffer size explicit and a specially crafted jpeg of 1024x768(native size not respected since jpeg drawer doesnt support it there) linux config enabled for CONFIG_X86_SYSFB=y and FRAMEBUFFER_COREBOOT=y and simplefb enabled under Heads and simple added under kexec patch: the system draws a splashscreen in millisecond, simplefb is useable by Heads without costy DRM kernel modules, and tinycore can be kexec'ed into in VESAFB mode.

Under qemu-coreboot for 135, its another story, Only bochs is supported for native init to show bootspash so qemu needs to be leunahced with std vga option and nothing else to be able boot into Heads with bochs drm enabled, which doesn't kexec properly inti VESA mode for the same reasons of non-exposed fb base memory address. If simplefb path is attempted, it works. But qemu is not refereshing drawn content for unknown reasons to me. Zooming in/out shows that it worked and its possible to kexec into VESA mode as well from simplefb.

And then, since Heads relies on fbwhiptail for its beautiful menus, fbwhiptail needs to be reworked a bit to work correctly with simplefb.

@paulmenzel I hope those notes makes the situation a bit clearer.

@paulmenzel as usual thanks for keeping an eye open like you do here.
I did a recap as well with screenshots and complementary information at #1381 (comment)

@paulmenzel any insights reading this?

#1398 is PoC of enabling libgfxinit in coreboot for all slower boards to have splashscreen while SPI is read and kernel is extracted until i915drmfb inits the db itself and takes over the fb.

But the general solution into getting simplefb driver is postponed. Nobody answered the call with the issue with qemu (q35) coreboot target and simplefb as of now. Know wsomeone I should direct the problem directly?

TLDR: More work needed under fbwhiptail to generalize the concept and take advantage of simplefb, not caring about drm. But qemu still requires bochs in coreboot to draw bootsplash, requiring kvm/qemu to use bochs there and where linux config is not able to drive fb with simplefb, outside of the fbwhiptail issues. That should be fixed somehow, but as of now, i'm not sure how to get collaboration fixing the issue.

#1398 gets things needed to easily toggle only the -vga std option from the board config to reproduce the issue.
Are you on matrix? Please add me there, that would be much more easier. I will update here consequently.

Next steps is to use changes for

• coreboot libgfxinit + bootsplash of master
• hack kexec to support simplefb
• enable kernel configs for simplefb
• point fbwhiptail on branch for simplefb https://source.puri.sm/firmware/fbwhiptail/-/commits/simplefb_shadow/

snippet of linux config changes to be applied

------------------- config/linux-librem_common-6.1.8.config -------------------
index 20564d0b..fd425fdc 100644
@@ -68,6 +68,10 @@ CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_ALLOW_DEV_COREDUMP is not set
 # CONFIG_FIRMWARE_MEMMAP is not set
 # CONFIG_DMIID is not set
+CONFIG_SYSFB_SIMPLEFB=y
+CONFIG_GOOGLE_FIRMWARE=y
+CONFIG_GOOGLE_COREBOOT_TABLE=y
+CONFIG_GOOGLE_FRAMEBUFFER_COREBOOT=y
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_BLK_DEV_RAM=y
 CONFIG_BLK_DEV_RAM_SIZE=65536
@@ -158,20 +162,11 @@ CONFIG_TCG_TPM=y
 CONFIG_TCG_TIS=y
 # CONFIG_RANDOM_TRUST_CPU is not set
 # CONFIG_RANDOM_TRUST_BOOTLOADER is not set
-# CONFIG_I2C_COMPAT is not set
-CONFIG_I2C_MUX=m
-CONFIG_I2C_MUX_PCA9541=m
-CONFIG_I2C_MUX_REG=m
-# CONFIG_I2C_HELPER_AUTO is not set
-CONFIG_I2C_SLAVE=y
 # CONFIG_HWMON is not set
 # CONFIG_X86_PKG_TEMP_THERMAL is not set
 CONFIG_MFD_SYSCON=y
-CONFIG_DRM=y
-CONFIG_DRM_I915=y
-CONFIG_DRM_AST=y
 CONFIG_FB=y
-CONFIG_FB_VESA=y
+CONFIG_FB_SIMPLE=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION=y
 CONFIG_USB_HID=m

Interesting success with simplefb and fbwhiptail new simplefb supporting branch.

Downside is since i915drmfb is not taking ownership of the console after libgfxinit fixates height x width of screen with limited size of splashscreen jpeg parser (only supports old sizes like 1024x768) then console is limited to that size (1024x768) until/if drm takes over on next kernel.

Tried to question coreboot at https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAtTc0IEVgQDycUJmB7PLulE?via=libera.chat&via=matrix.org&via=matrix.zerodao.gg let's see what happens.

oooooold code https://github.com/coreboot/coreboot/blame/396201c1ef52c14777a756d1962e18251a338076/src/lib/jpeg.c

Wow, today and yersterday were fruitful collaboration days with coreboot!

Thanks to Nico Huber (icon on coreboot) for 3 patches: https://review.coreboot.org/c/coreboot/+/76431 and https://review.coreboot.org/c/coreboot/+/76424 and fbwhiptail patch against @JonathonHall-Purism 's fbwhiptail simplefb branch, we now have unified efifb driven graphics (FSP GOP/native gfx/libgfxinit), smaller splashscreen then native resolution support (centering instead of failing) and qemu support with same efifb driver configuration, resolving the weird issue we had prior with qemu and simplefb not refreshing qemu window (a problem that is unfixed but that nobody cared for)

@JonathonHall-Purism If you want to point me to tested commit for librems, I can add them here!
We now have blazing fast fbwhiptail and no more weird hacks nor dependencies on i915drmfb.

CC: @paulmenzel

Note that the buildsystem is now producing sizes.txt for each board builds artifacts, to be easily comparable directly between builds with diff -u command.

Comparison for x230-hotp-maximized:

• this PR sizes.txt
• master's sizes.txt

wget -q https://output.circle-artifacts.com/output/job/8e71e322-166f-4475-986f-5dad6e8ea1a0/artifacts/0/build/x86/x230-hotp-maximized/sizes.txt -O /tmp/1403
wget -q https://output.circle-artifacts.com/output/job/d278720c-f578-4355-832b-cc83320c3d2e/artifacts/0/build/x86/x230-hotp-maximized/sizes.txt -O /tmp/master
diff -u /tmp/master /tmp/1403
--- /tmp/master	2023-07-12 21:34:15.000000000 -0400
+++ /tmp/1403	2023-07-14 14:41:26.000000000 -0400
@@ -1,5 +1,5 @@
-2023-07-12 21:29:30-04:00 d7d93484eb24c24422fb710a2ca16bf5b64d23b7 clean
- 3053888:/root/project/build/x86/x230-hotp-maximized/bzImage
+2023-07-14 14:18:08-04:00 35d6c198b390e4b2734fb5ca745923231f810840 clean
+ 2480256:/root/project/build/x86/x230-hotp-maximized/bzImage
   685056:/root/project/build/x86/x230-hotp-maximized/modules.cpio
 -----
   304040:./lib/modules/e1000e.ko
@@ -9,7 +9,7 @@
    11544:./lib/modules/xhci-pci.ko
   128632:./lib/modules/usb-storage.ko
 -----
-11240448:/root/project/build/x86/x230-hotp-maximized/tools.cpio
+11244544:/root/project/build/x86/x230-hotp-maximized/tools.cpio
 -----
   596544:./lib/libc.so
   491024:./lib/libcairo.so.2
@@ -59,7 +59,7 @@
    10096:./bin/poke
    14240:./bin/cbfs
    14208:./bin/uefi
-   39432:./bin/fbwhiptail
+   43528:./bin/fbwhiptail
       35:./bin/whiptail
    29944:./bin/hotp_verification
     1087:./bin/hotp_initialize
@@ -145,5 +145,5 @@
      924:./sbin/config-dhcp.sh
     1064:./sbin/insmod
 -----
- 4219904:build/x86/x230-hotp-maximized/initrd.cpio.xz
-12582912:/root/project/build/x86/x230-hotp-maximized/heads-x230-hotp-maximized-v0.2.0-1712-gd7d9348.rom
+ 4218880:build/x86/x230-hotp-maximized/initrd.cpio.xz
+12582912:/root/project/build/x86/x230-hotp-maximized/heads-x230-hotp-maximized-v0.2.0-1716-g35d6c19.rom

Some analysis:
What interests us here is

• the size difference of the kernel (bzImage) not packing i915drmfb related material and efifb instead (3053888 - 2480256 = 573632)
• the size difference of tools.cpio (fbwhiptail change) packed under initrd.cpio.xz (4219904 - 4218880 = 1024)
  For a total gain of 573632 + 1024= 574656 bytes!
• This also reduces the boot time of around 2-3 seconds for x230.

Note on kexec hack that seems unneeded:
setup_linux_vesafb: Found driver EFI VGA, providing VIDEO_TYPE_EFI

Removing efifb in kexec's VLFB fb address passing hack to next kernel: unneeded since EFI detected :)

trampoline efifb https://review.coreboot.org/c/coreboot/+/76431 patch updated upstream to patchset 4, rebasing

Was merged as patch set 6, needs rebasing

Starting cleanup of commits.
First, squash commit to not impact librem boards coreboot configs.

Cleaning up commit logs: squash WiP commits related to legacy-flash/legacy that were not working

Will pass t430 boards to untested by the end of the week. if still untested.

As of today the following boards flavors are accumulating non-testing since they were moved to untested anyway:

* ~UNTESTED_p8z77-m_pro-tpm1-maximized UNTESTED_p8z77-m_pro-tpm1-hotp-maximized~ : my bad. Adding commit to this PR to bring it back

* UNTESTED_t520-hotp-maximized UNTESTED_t520-maximized

* UNTESTED_t530-dgpu-hotp-maximized UNTESTED_t530-dgpu-maximized

* UNTESTED_w530-dgpu-K1000m-hotp-maximized UNTESTED_w530-dgpu-K1000m-maximized  UNTESTED_w530-dgpu-K2000m-hotp-maximized UNTESTED_w530-hotp-maximized UNTESTED_w530-maximized

So if my assessment is correct: of all currently untested boards of OP.

Currently, said tested boards will move to untested by the end of the week:

• t430 boards will move to untested until brought back one by one (t430-maximized/t430-legacy/t430-legacy-flash)
• Add HP Z220 CMT #1399: @d-wid : libgfxinit efifb prepared fb + linux efifb + centered 1024x768 bootsplash (3 second boottime reduction) is currently untested and will be renamed accordingly.

Other boards are currently untested and will stay like that:

• t520 has not been tested by anybody for a long time, seems like nobody cares
• t530 (iGPU)/ dGPU flavors : those boards need testing and will stay as untested.
• w530 (iGPU/ dGPU flavor): those boards need testing and will stay as untested.

TLDR: t430 and z220 boards are on the verge of being moved to untested while other boards currently untested will stay untested.

Did I miss an update after #1403 (comment) ? (That one was on the Z220, didn't mention that in the reply)

@d-wid I take liberty to edit that comment with a link to your previous one. Thought you tested edp, didn't clicked on the link you provided myself. Let's be clearer in the future. :)

kexec should be better now, less flicker! Could be used as daily driver, will land under master soon (once all boards builds successfully even if UNTESTED). Please report issues if any in seperate issue.

So only t430 boards flavors are adding up to the untested boards from this PR (which are added to currently untested board list until people show up to test those and move them back out of untested boards).

Moving them to untested until tested. This means what it means. They should not be flashed by general public without external flashing capability to unbrick, preferably by owners wanting the board to be fully supported and maintained as the work is done for other boards. Boards need to be tested by boards owners in a better collaboration in the future. Will try to find better ways to reach owners and willing testers and resellers....

Specific post for this PR on QubesOS forum at https://forum.qubes-os.org/t/heads-needs-testers-with-external-programmers/19564/14

Closes issue #1467

Can confirm heads-t430-maximized-v0.2.0-1747-g572573f.rom works

Will remove t430-maximized from untested board.... Thanks @srgrint for testing this out last minute prior of merging

Did I miss an update after #1403 (comment) ? (That one was on the Z220, didn't mention that in the reply)

@d-wid I take liberty to edit that comment with a link to your previous one. Thought you tested edp, didn't clicked on the link you provided myself. Let's be clearer in the future. :)

Yeah my bad, will do,

heads-t430-hotp-maximized-v0.2.0-1750-g97f39a8.rom works (sorry for the delay)